home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Performance Co-Pilot 1.3
/
SGI Performance Co-Pilot 1.3.iso
/
dist
/
pcp.idb
/
usr
/
share
/
catman
/
u_man
/
cat4
/
pmns.z
/
pmns
Wrap
Text File
|
1997-04-03
|
9KB
|
246 lines
PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444))))
NNNNAAAAMMMMEEEE
ppppmmmmnnnnssss - the performance metrics name space
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
/_v_a_r/_p_c_p/_p_m_n_s
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
When using the Performance Metrics Programming Interface (PMAPI) of the
Performance Co-Pilot (PCP), performance metrics are identified by an
external name in a hierarchic Performance Metrics Name Space (PMNS), and
an internal identifier, the Performance Metric Identifier (PMID).
A PMNS specifies the association between a metric's name and its PMID.
A PMNS is defined on one or more ASCII source files, that may be compiled
using ppppmmmmnnnnssssccccoooommmmpppp(1) to produce a binary PMNS.
Client applications above the PMAPI use ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) to load a
PMNS, and ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) silently tolerates either the ASCII or
binary formats. Alternatively, ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) may be used to
load just the ASCII format.
If the binary format is used, no checking is performed for aliasing in
which multiple names in the PMNS are associated with a single PMID. If
the ASCII format is to be used, duplicate PMIDs are not allowed, although
ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) provides an alternative interface with user-
defined control over the processing of duplicate PMIDs in an ASCII format
PMNS.
There is one default PMNS in the files below /_v_a_r/_p_c_p/_p_m_n_s, although
users and application developers are free to create and use alternate
PMNS's. For an example of this, see the PCP Tutorial in
/_v_a_r/_p_c_p/_d_e_m_o_s/_T_u_t_o_r_i_a_l.
Use the environment variable PPPPMMMMNNNNSSSS____DDDDEEEEFFFFAAAAUUUULLLLTTTT to specify the pathname to a
file containg the root of an alternative default PMNS, else the ----nnnn
command line option may be used with most PCP applications.
The external ASCII format for a PMNS conforms to the syntax and semantics
described in the following sections.
PPPPRRRROOOOCCCCEEEESSSSSSSSIIIINNNNGGGG FFFFRRRRAAAAMMMMEEEEWWWWOOOORRRRKKKK
The PMNS specification is initially passed through ccccpppppppp(1). This means
the following facilities may be used in the specification
+ C-style comments
+ #_i_n_c_l_u_d_e directives
+ #_d_e_f_i_n_e directives and macro substitution
PPPPaaaaggggeeee 1111
PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444))))
+ conditional processing via #_i_f ... #_e_n_d_i_f, etc.
When ccccpppppppp(1) is executed, the ``standard'' include directories are the
current directory and /_v_a_r/_p_c_p/_p_m_n_s.
SSSSYYYYNNNNTTTTAAAAXXXX
The general syntax for a non-leaf node in the PMNS is as follows
pathanme {
name [pmid]
...
}
Where _p_a_t_h_n_a_m_e is the full pathname from the root of the PMNS to this
non-leaf node, with each component in the pathname separated by a ``.''.
The root node for the PMNS must have the special name ``root'', but the
common prefix ``root.'' must be omitted from all pathnames. Each
component in the pathname must begin with an alphabetic character, and be
followed by zero more characters drawn from the alphabetrics, the digits
and the underscore ``_'') character. For alphabetic characters in a
pathname component, upper and lower case are distinguished.
Non-leaf nodes in the PMNS may be defined in any order.
The descendent nodes are defined by the set of _n_a_m_e_s, relative to the
_p_a_t_h_n_a_m_e of their parent non-leaf node. For the descendent nodes, leaf
nodes have a _p_m_i_d specification, non-leaf nodes do not. The syntax for
the _p_m_i_d specification has been chosen to help manage the allocation of
PMIDs across disjoint and autonomous domains of administration and
implementation. Each _p_m_i_d consists of 3 integer parts, separated by
colons, e.g. 14:27:11. This hierarchic numbering scheme is intended to
mirror the implementation hierarchy of performance metric domain, metrics
cluster (data structure or operational similarity) and individual metric.
In practice, the two leading components are likely to be macros in the
PMNS specification source, and ccccpppppppp(1) will convert the macros to
integers. These macros for the initial components of the _p_m_i_d are likely
to be defined either in a standard include file, e.g.
/_v_a_r/_p_c_p/_p_m_n_s/_s_t_d_p_m_i_d, or in the current source file.
The current allocation of the high-order (PMD or domain) component of
PMIDs is as follows.
___________________________________
Range Allocation
___________________________________
0 reserved
___________________________________
1-31 SGI internal
___________________________________
32-39 Oracle
___________________________________
___________________________________
|||||||||
|||||||||
|||||||||
PPPPaaaaggggeeee 2222
PPPPMMMMNNNNSSSS((((4444)))) PPPPMMMMNNNNSSSS((((4444))))
40-47 Sybase
___________________________________
48-55 Informix
___________________________________
56-127 ISV Performance Metrics
___________________________________
128-254 End-user applications
___________________________________
||||||||
||||||||
||||||||
EEEEXXXXAAAAMMMMPPPPLLLLEEEE
#define IRIX 1
root {
network
cpu
}
#define NETWORK 26
network {
intrate IRIX:NETWORK:1
packetrate
}
network.packetrate {
in IRIX:NETWORK:35
out IRIX:NETWORK:36
}
#define CPU 10
cpu {
syscallrate IRIX:CPU:10
util
}
#define USER 20
#define KERNEL 21
#define IDLE 22
cpu.util {
user IRIX:CPU:USER
sys IRIX:CPU:KERNEL
idle IRIX:CPU:IDLE
}
SSSSEEEEEEEE AAAALLLLSSSSOOOO
ppppmmmmnnnnssssccccoooommmmpppp(1), PPPPMMMMAAAAPPPPIIII(3), ppppmmmmEEEErrrrrrrrSSSSttttrrrr(3), ppppmmmmLLLLooooaaaaddddAAAASSSSCCCCIIIIIIIINNNNaaaammmmeeeeSSSSppppaaaacccceeee(3) and
ppppmmmmLLLLooooaaaaddddNNNNaaaammmmeeeeSSSSppppaaaacccceeee(3).
PPPPaaaaggggeeee 3333